Community antenna television (“CATV”) networks have been used for more then four decades to deliver television programming to a large number of subscribers. Increasingly, CATV networks are used by providers to provide data services to subscribers. For example, cable modems used in a broadband cable modem termination system (“CMTS”) are capable of transmitting and receiving Internet data using the Data Over Cable Service Interface Specification (“DOCSIS”) protocol. DOCSIS provides a standard that allows network devices made by different vendors to communication with one another.
Similar to DOCSIS, which is administered by Cable Television Laboratories, Inc. (CableLabs®), “PacketCable™is a CableLabs-led initiative aimed at developing interoperable interface specifications for delivering advanced, real-time multimedia services over two-way cable plant. Built on top of the industrys highly successful cable modem infrastructure, PacketCable networks will use Internet protocol (IP) technology to enable a wide range of multimedia services, such as IP telephony, multimedia conferencing, interactive gaming, and general multimedia applications.”DOCSIS and PacketCable are protocol standards known in the art and do not require further discussion of their basic functioning. However, it will be appreciated that, although DOCSIS and PacketCable are currently considered industry standards, other protocol standards may become predominant over time. Thus, for purposes of discussion herein, DOCSIS may be generically referred to as a ‘data protocol’and PacketCable as a ‘multimedia protocol.’
In a broadband cable data network using a multimedia protocol, such as PacketCable, call traffic signals are typically processed by a CMTS. Thus, in addition to bandwidth capacity of the network, processing capabilities in the CMTS may impose a practical limit on the amount of traffic, either data or voice or multimedia, that can be processed by the CMTS. For example, processor resources in a CMTS typically are used to for call traffic signal processing, which may include—authorization, admission control and resource allocation. In addition to call signal processing, the processor may also be performing system function—traffic policing and shaping, ingress noise avoidance, fault management, and statistics collection. Therefore, there is a limit to the number of functions/processes that a processor can perform at a given instant. Moreover, since each call requires significant processor resources, there is a finite limit to the number of calls that a CMTS can process within a given amount of time. This can result in delayed dial tone, failed call setups and slow call teardowns.
When a voice call has been initiated, but the processor is overloaded, subsequent call signaling events may experience excessive latency. If a caller has already spent time dialing a number, waiting for a connection and has begun to converse with the other party, and then one of the aforementioned undesirable effects occurs, any subsequent call signaling events (codec upgrade, call waiting, call teardown, etc.) may experience excessive latency—perhaps to the point of not working at all. This can lead to frustration and wasted time.
To prevent this situation from occurring, the processor-load state has been categorized according to how lightly or heavily the processor is loaded. For example, if the processor is lightly loaded, the load state would be categorized as ‘Normal.’ When the processor is heavily loaded, it would be categorized as ‘Red.’ And, intermediate category would be ‘Yellow.’ When the CMTS processor is operating in a more loaded state, any new call request messages may be met with an increased likelihood of a denial of service. In other words, the call request is not granted, and the user would be presented with a signal indicating as much, such as, for example, a ‘fast busy’ signal that traditionally indicates that all circuits are busy. This would indicate that the caller should try calling back later. While this achieves the goal of preventing the user's call session from being started and then terminated, it can often lead to an inefficient use of resources, as the processor may be capable of handling more calls, even though it is in the Red category.
Furthermore, a call request may be presented to a CMTS in various formats. For example, when using PacketCable, as known in the art, messages are sent to the CMTS from a call management server (“CMS”), that observes when a caller's phone is placed ‘off hook’ and performs preliminary messaging between the callers customer premise equipment (telephone, cable modem, etc.) and the CMTS. The CMS may send a message to the CMTS informing it that a call is about to be placed, and that a gate (policy object) placeholder needs to be reserved. This placeholder request message contains minimal information necessary in order to reserve a ‘place in line’ for the call and to thereby generate a corresponding gate identifier to be used by the side of the call, but does not convey all of the information the CMTS needs in order to complete the call.
In contrast, the CMS may also send a gate results when the device being called has acknowledged that it will receive the call, and has responded with a message containing the signaling information needed to complete the call. In response, the device from which the call is placed generates and sends a complete signaling information message to the CMTS to which connects, and the call is completed when the CMTS loads this signaling information and connects the caller to the party being called.
Using PacketCable nomenclature, the call request which results in an identifier is referred to as a Gate-Alloc, which asks the CMTS to allocate a dynamic quality of service gate (“DqoS gate”) to the originating subscriber. A message containing the complete signaling information is referred to as a Gate-Set message, which contains much more information related to the call than the Gate-Alloc message. Accordingly, more CMTS resources, i.e. processor resources, are used in processing a Gate-Set message than in processing a Gate-Alloc message.
Thus, when many Gate-Set messages have been or are being processed, the CMTS processor load is high and may enter the Red category. Presently, CMTS evaluate whether the processor is operating in the red category. Of so, other system functions as well as further call requests (Gate-Alloc messages) may be denied. However, this can waste CMTS processor resources, because the threshold at which the processor is deemed to be operating in the red is typically selected to occur before the processor actually has no remaining processor capacity to offer another call request. This results in call requests being denied, and therefore frustration to the callers as well as loss of revenue to the operator.
Therefore, there is a need in the art for a method that more efficiently uses CMTS resources so that more of a processors capacity is used in processing calls without causing a call to be dropped after it has been started.